Regulatory Open Forum

 View Only
Expand all | Collapse all

Change request form/template

  • 1.  Change request form/template

    This message was posted by a user wishing to remain anonymous
    Posted 05-Nov-2018 12:26
    This message was posted by a user wishing to remain anonymous

    Wondering if there is a best practice for implementing changes in the Medical device/IVD industry. For example a comprehensive change request form that is used to identify, assess and implement a Design change?
    Thanks for sharing your input.
    A


  • 2.  RE: Change request form/template

    Posted 06-Nov-2018 06:36
    Many years ago we had a Document Change Order (DCO)/Engineering Change Order (ECO)/Manufacturing Change Order (MCO) - had a few different terms that just listed the document number, old revision, new revision, description of change, maybe a rationale, and approval section.  Now change orders are quite comprehensive because impact to product, processes, and overall quality system need to be assessed.  The rationale or justification change section needs to be detailed explaining why something is changing, what is changing, related processes, etc. - it may no longer be a simple statement saying "update specification".  In addition, change orders we put in place for quality systems have a whole battery of questions and risk-impact based on the change.  These are typically yes/no with a risk impact statement.  These cover multiple areas, not all inclusive, but include areas like inventory, products in the field, regulatory registration, design change, indications for use. QMS processes, manufacturing processes, finished device testing, labelling, claims, notification to regulatory agency, regulatory general, quality general, etc.  This of course is tailored toward the type of company (full manufacturing versus virtual manufacturer) and type of device (Class I to III).  But simple answer is yes a change order process is definitely needed in order to understand and document change impacts to the quality system and product.​

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------



  • 3.  RE: Change request form/template

    This message was posted by a user wishing to remain anonymous
    Posted 06-Nov-2018 08:39
    This message was posted by a user wishing to remain anonymous

    There is no set form for design change.  
    That said, I have used the following questions on company Change Request Form and have received positive feed back from auditors, FDA and NB.

    Questions to consider relating to Change Request:

    Y

    N

    Task to be completed for condition identified

    Is this an initial release of a Quality System document or form?

     

     

    If yes, the training matrix must be modified to include this new document/form and be included as part of this Change Request (CR).

    Is this a change to an existing Quality System document or form?

     

     

    If yes, attach current Training Matrix.

    Is this an initial release or change to XYZ generated (for XYZ or Customer) product labeling or Instruction for Use (IFU) or e-IFU?

     

     

    - If yes, attach print specification and XYZ Proof of printed pieces.

            If artwork is for customer, attach their approvals of proof.

    - For product sold in Canada or EU attach appropriate notification sent to Health Canada and/or Notified Body.

    Is this an initial release or change to customer generated labeling?

     

     

    If yes, attach customer artwork file and print specification. Obtain and attach customer approvals.

    Is this an initial release for a product specification?

     

     

    If yes, changes to the Device Master Record (DMR) are required.

    Attach redlined DMR.

    Is this a design modification or revision to product specification that will change form, fit or function of an on-market product?

     

     

    - If yes, changes to the BOM, drawings, product specification, validation protocol, and Tech File may be required. Please attach.

    - If yes, product validation / verification is required. Provide Validation/ Verification Summary Report

    - For product sold in Canada or EU attach appropriate notification sent to Health Canada and/or Notified Body.

    Is this a design change/modification to product sold as a Private Label or to an OEM customer?

     

     

    - If yes, attach a list of all Private Label customers for the product impacted by this change.

    - Attach copies of the notifications sent to the customers impacted by this change.

    Will this modification require a change to the current tooling/equipment?

     

     

    If yes, tooling validation is required.

    Provide Tooling Validation Summary Report.

     

    Is this the initial release or a revision change to a test procedure or validation protocol and/or validation data logs?

     

     

    If yes, changes to the DMR, Tech File, DHF, related data logs, test procedures, validation protocols may be required. Attach documents.

    Is this an initial release of product or a modification to "intended use", a brand name change, manufacturer name or address change, device name change, addition or removal of device catalog number?

     

     

    If yes, Tech File update required.

     

    If yes, regulatory authority (FDA, Health Canada, EU Notified Body) notification is required.

     

    Attach notifications.                                                                                                                                                                                                          

    Will this change require the ASL to change?

     

     

    If yes, update ASL and attach it as part of this Change Request.




  • 4.  RE: Change request form/template

    Posted 08-Nov-2018 16:54

    Proper design change in the medical device/IVD industry requires careful attention to several critical principles such as:

     

    • Design control (i.e., design inputs, outputs, verification, validation, transfer, etc.) applies to design of the product, but also to design of the product's manufacturing process (even when manufacturing is outsourced).
    • Because design controls apply to the product and its manufacturing process, this consequently demands that the "design change" requirements of FDA 21 CFR 820.30(i), ISO 13485:2016 clause 7.3.9, etc., be applied not only to the product, but also to the manufacturing process.
    • Design change controls apply during the development process prior to first market launch as well as after market launch.


    We could easily have an entire discussion about the nuances of how design control applies to manufacturing processes, but that seems beyond the direct intent of this current thread.  For now, I'll just say that if anyone is uncertain about the requirement for applying design controls to a product and its manufacturing process, here are a few supporting sources:

     

    • FDA's design control guidance states, "…The guidance applies to the design of medical devices as well as the design of the associated manufacturing processes…Design control begins with development and approval of design inputs, and includes the design of a device and the associated manufacturing processes…Design control applies to all changes to the device or manufacturing process designthe concurrent engineering model properly emphasizes that the development of production processes is a design rather than a manufacturing activity…"
    • FDA Device Advice states, "…There are specific requirements for design changes and they have to identify, document, validate or verify, review and approve all the design changes…And please remember, the design changes are not just changes to the device itself; design changes include any changes to the processing, to the manufacturing process, any changes to the testing that you're doing during production, because all of that needs to be considered during your design and development…technically, 820.70(b) – the requirement that says they have to have establish procedures for changes to specification, method, and process or procedures – has to be done according to 820.30 design controlsThis really is a redundant requirement with the design change control requirement…"
    • ISO 13485:2016 clause 7.3.3(e) states, "…[design inputs] shall include…requirements essential for the design and development of the product and processes" [emphasis added by ComplianceAcuity]. Likewise, ISO/TC 210 gives more hints about this in its ISO 13485:2016 practical guide where it adopts the aforementioned FDA concurrent engineering principles and states that, "…This addition [ISO 13485:2016] highlights the need to consider manufacturability in the design and development processthe manufacturing process should be capable and stable to consistently produce product that is safe and performs as intended…", moreover showing that process design inputs are needed for in-house and outsourced manufacturing alike.

     

    With these basic design control principles in mind, let's take a closer look at some "best practices" for design change.

     

    Specifically, the proper management of design changes for products and manufacturing processes demands the proper identification, documentation, and handling of each affected product/process user need, design input and/or design output along with the corresponding design verification, validation, and transfer. But most often, I find that medical device companies' change control mechanisms include a rather orphaned verification/validation step that doesn't clearly assure full consideration of the intrinsic thread running all the way back to the initiating user need and design input.  Such procedural vulnerabilities are no surprise in light of variables like FDA's potentially misleading regulatory separation of 21 CFR 820.70(b) from 820.30(i), when in reality these are one and the same requirement (as explained above).  Accordingly, it is important to remember for example the fundamental definition of "design verification", which is to confirm that the design output satisfies a design input.  Proper attention to such fundamentals will reduce the chances of the misdirected verification/validation planning so often resulting in colorful and impressive-looking data, effort, charts and reports (thereby apparently justifying the change), but that don't actually achieve the basic intention of design change verification/validation, which is innately linked back to specific user needs and design inputs.

     

    So always remember that the FDA/ISO requirement to verify/validate a change inherently means there is a corresponding revised design output and by default perhaps also an affected user need and design input.  For example, a faulty device design may be changed in order to better meet user needs.  It could be the case that the user needs (and related design inputs) weren't sufficiently defined during the original design effort.  In such a case, the change would first need to include recording of new or revised design inputs, followed by processing accordingly through the remaining design control steps (i.e., revised outputs with corresponding design verification and/or validation and transfer).  Apart from this type of systematic, methodical approach, it leaves open the possibility for insufficiently-controlled design changes.

     

    On that note, to help illustrate the handling of these principles, I've included two model change control forms leveraged by ComplianceAcuity when helping clients build or improve their design change mechanisms:

     

    • Attached Model 1 shows an abbreviated way to handle the topic and is reflective of the way many change control forms look. Though certainly efficient and generally compliant, Model 1 requires a high level of dynamic fluency in design change controls and/or may also need to be supplemented by narratives in your design change SOP or Work Instructions to assure the proper design control implications and questions will be answered.

    • Attached Model 2 shows a methodical/systematic approach where the change's specific implications are comprehensively analyzed in more proper design control terms. Consequently, Model 2 is lengthy and for demonstration purposes only. Though it could certainly be implemented "as-is" and shows proper management of design change implications, Model 2 may not be a sustainable option as currently formatted.

     

    Hope this helps point you in the right direction.

    ------------------------------
    Kevin Randall, ASQ CQA, RAC (U.S., Canada, Europe)
    Principal Consultant
    ComplianceAcuity, Inc.
    Golden CO
    United States
    www.complianceacuity.com
    © Copyright 2018 by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------



  • 5.  RE: Change request form/template

    Posted 11-Nov-2018 04:20
    I noticed throughout this whole thread one thing lacking is consideration of compliance testing previously done.  What I am talking about is the impact of a label change or a design change (even simple ones) can have an impact on the IEC 60601 Series of standards (Medical Electrical Equipment) or I am sure of many other standards, as well.  But there really needs to be an expert review against the standards previously applied if a Change is being analyzed.  A change in an LED color or the type of switch used or internal wiring all may have an impact on a slew of standards that apply to the product.  Which could mean a simple revision to the Test House report without retesting to a significant retesting of the device to a full testing of the device.   When I worked for a Med Dvc Co. full time I had to review every single ECO, spec sheet changes, etc.

    There are so many standards that apply to medical devices and seems to be increasing at an exponential rate that you probably need to rely on multiple experts to do this review.

    So, some additional questions to ask on an ECO form would be:
    1) <g class="gr_ gr_2312 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" id="2312" data-gr-id="2312">Does</g> these changes impact the Safety Agency Test Reports
    2) Do these changes impact EMC (Emissions/Immunity) 
    3) Do these changes impact Coexistence  
    4) Do these changes impact the Usability Engineering File (Human Factors)
    5) Do these changes impact the Software Lifecycle Process
    6) Do we need to notify UL, CSA, TUV, etc. (Test House or Agency for Marks) or does change require partial/full retesting)
    7) Etc.


    ------------------------------
    Leonard (Leo) Eisner, P.E.
    The "IEC 60601 Guy"
    Principal Consultant, Eisner Safety Consultants
    Phone: (503) 244-6151
    Mobile: (503) 709-8328
    Email: Leo@EisnerSafety.com
    Website: www.EisnerSafety.com
    ------------------------------



  • 6.  RE: Change request form/template

    Posted 01-Apr-2019 13:11
      |   view attached
    Updated version attached with ISO 13485:2016 features added and ​more streamlined.

    ------------------------------
    Kevin Randall, ASQ CQA, RAC (U.S., Canada, Europe)
    Principal Consultant
    ComplianceAcuity, Inc.
    Golden CO
    United States
    www.complianceacuity.com
    ------------------------------

    Attachment(s)



  • 7.  RE: Change request form/template

    Posted 11-Nov-2018 12:17

    Great comments by Leo (the "IEC 60601 Guy") about the importance of properly addressing electrical safety testing, usability, and a wide variety of other elements during a design change.

    I find that change control forms often have a staggering array of various questions aimed at boosting the chance that all the necessary verification/validation will be addressed.  For example, I recently saw a change control form with at least 22 such questions in a checklist-type arrangement.  But I've noticed that design change authors/reviewers/participants using such forms often get overwhelmed by, or tune out, such lists of questions.  This troubling dynamic seems to happen because, typically, most of the questions in such lists don't apply to the change at hand. In other words, if we try to prospectively author a standardized list of questions in hopes of accommodating the full spectrum of future changes, then the answer to such questions most often turns out to be "No" or "N/A", consequently forcing the team to scour through the list (or their imaginations) trying to find the one or two verification/validation elements that might apply. And oftentimes, I've seen that none of the questions in such lists apply at all, thereby forcing supplemental narratives to be written and added in a text block. After design teams endure a few repetitions filling out such paperwork, I've found that they start to resent and dismiss such lists (and the quality/regulatory department who designed the form) as a waste of time since the form asks so many questions not directly relevant to the change at hand.

     

    Further to my prior post, every change requires some type of verification and/or validation, thus begging critical questions underlying great comments like Leo's. Specifically, how do we know exactly which testing is needed? How do we avoid missing something like a required electrical safety or usability test? Well, the beauty of the approach conceptualized in forms like Model 2 is that a true design-focused paradigm is employed for each design change in order to organically, methodically, and deliberately identify exactly which testing, data, documents, etc., are actually relevant to the particular change. This is assured because forms like Model 2 aim to be anchored by a proper underlying foundation of core design control principles. In particular, the verifications/validations being considered during these changes are in fact design verifications/validations intrinsically linked back to specific design inputs embodied to address the need for electrical safety, usability, electromagnetic compatibility, biocompatibility, sterility, manufacturability, and so on and so forth.

     

    By staying cognizant of the thread between design change verification/validation and the originating design inputs, it should reduce the rate of insufficient change verifications/validations, and thus should lead to less recalls, safety problems, failed manufacturing transfers, design team fatigue/anxiety, etc. If we employ something like Model 2's approach to smartly and organically derive the applicable design verification/validation elements, then I believe our design change efforts will more efficiently and effectively address the necessary aspects of each design change.

    ------------------------------
    Kevin Randall, ASQ CQA, RAC (U.S., Canada, Europe)
    Principal Consultant
    ComplianceAcuity, Inc.
    Golden CO
    United States
    www.complianceacuity.com
    © Copyright 2018 by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------



  • 8.  RE: Change request form/template

    Posted 12-Nov-2018 02:28
    I agree with Kevin's last comment but the one thing I do see is there are many medical device companies that are small to mid-size that don't have the expertise in-house for all the standards, requirements, regulations, <g class="gr_ gr_526 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="526" data-gr-id="526">guidances</g>, etc. to assess design changes fully and so ECOs don't always address these issues.  Even if just a few questions to remind the ECO authors & any RA/QA support to think about if there are implications for X, Y, & Z (Say Regulators, Safety Test Houses, etc.) many times the specifics applicable to standards, etc. are missed and then the ECO is done without updating the proper V&V testing, documentation review, etc.

    ------------------------------
    Leonard (Leo) Eisner, P.E.
    The "IEC 60601 Guy"
    Principal Consultant, Eisner Safety Consultants
    Phone: (503) 244-6151
    Mobile: (503) 709-8328
    Email: Leo@EisnerSafety.com
    Website: www.EisnerSafety.com
    ------------------------------



  • 9.  RE: Change request form/template

    Posted 13-Nov-2018 08:36
    We're a small medical device manufacturer, but we recently updated our Change Management workflow in Arena PLM to meet the ISO 13485:2016 requirements of integrating risk management into the design change process.  We have the workflow set up in 4 sections: Change Description and Rationale, Change Level Assessment, Risk Management / Validation & Verification, and Implementation Plan.  I've pasted the fields below.

     

    ECO Title  

    Change Description 

    Change Rationale

    <Provide the rationale for the change, the change level and implementation class. This may include test reports, FMEA, etc. Describe validation or verification plans or provide a rationale for why they are not needed. Additional files can be added in the Files View of the Change later in the workflow, if needed. >

     

    Change Level Assessment

    Technology Change Assessment

    Control mech/operating principle/Energy type changed? Select one... YES NO 

     

    Formula Impact Assessment

    Formulation changed? Select one... YES NO 

     

    Sterility Impact Assessment

    Material/permeability of a sterile barrier changed? Select one... YES NO 

     

    Fluid Path / Biocompatibility Assessment

    Material of a fluid path component changed? Select one... YES NO 

     

    EO Cycle Impact Assessment

    Product density changed beyond validated range? Select one... YES NO 

     

    Specification Assessment

    Release Criteria/Specification changed? Select one... YES NO 

     

    Labeling & Claims Assessment

    Product claims changed? Select one... YES NO 

     

    User/Design Requirements Assessment

    Ability to meet User & Design Requirements impacted? Select one... YES NO 

     

    Supplier of a critical component or finished good assembly changing? Select one... YES NO 

    <New suppliers for critical components or finished good assembly may require validation and/or verification.>

     

    Other reason to elevate change to MAJOR? Select one... YES NO 

    <If YES, document the rationale for elevating the change to MAJOR in the Change Level Notes field.>

     

    Change Level Assessment Notes

    <If the change is Major due to some other factor, describe the rationale here.>

     

    Change Level     Select one... MINOR MAJOR 

    <If the answer to any of the above questions is "YES", the change level should be MAJOR.>

     

    Risk Management / Validation & Verification

    Risk Management File Review Outcome                             Select one:

    • Minor Change. RMF Review not required.
    • RMF Reviewed. No changes required.
    • RMF Reviewed. See comments below for required updates.

    <Document the review and outcome. If updates are required to the RMF, describe them in the comments section below.>

     Risk Management File Notes

    <Add notes here if changes are required to the RMF.>

     

    Validation/Verification Assessment Results          Select one:

    • Minor Change. V&V not applicable.
    • No additional V&V required. See rationale below.
    • Additional V&V is required as described below. V&V results will be attached to the ECO.

    <Review User/Design Requirements as part of the V&V assessment.>

     

    Verification and Validation Notes

    <N/A if Minor change. Describe rationale if Major change does not require V&V or describe plan for V&V of Major change.>

     

    Implementation Plan

    Customer notification required? Select one... YES NO 

    <Advance notification of some major changes may be required by some customer contracts.>

     

    Regulatory notification required? Select one... YES NO 

    <Regulatory Impact Assessment>

     

    Supplier Notification Required? Select one... YES NO 

    <if needed, SME will contact supplier to share the new drawing or requirement document.>

     

    New Supplier required? Select one... Yes No 

    <If supplier is not yet approved, complete evaluation and approval per QMS-PR-7401.>

     

    ERP Update required? Select one... YES NO 

    <Materials Manager will coordinate with Accounting using Form QMS-FR-4203.>

     

    Training Required? Select one... Yes No 

    <QA will coordinate ORS training unless otherwise specified in the Implementation Notes.>

     

    Implementation Class    Select one...

    Class 1 Class 2 Class 3 Class 4 

    <Refer to QMS-PR-4204 for implementation class.>

     

    * Implementation Notes N/A

    <Describe the implementation plans. Evidence of implementation can be added to the Items, Files or Implementation tab of the ECO as appropriate.>



    ------------------------------
    Christopher Hill MBA, CQE, RAC
    Director of Quality
    Bolingbrook IL
    United States
    ------------------------------



  • 10.  RE: Change request form/template

    Posted 04-Dec-2018 19:35

    When I first came into the QA/RA profession back in the 1990's, design controls were one of the first QA/RA elements on which I was trained and mentored by some of the best design control experts in the field. This included attention drawn to FDA's mountain of historical data showing that lack of proper design controls leads to more recalls. Truth be told, that stuff was for me just a bunch of theory and marginal text-book knowledge back then when I was still so young and thus thought I was so much smarter than everyone else. Honestly, I didn't give it too much credence, incorrectly suspecting that FDA's data were just scare-tactics being used to disarm the industry's concerns about the burden of the new design control regulations.

     

    But in the decades thereafter, I've seen those text-book theories and data proven in real life time and again. For example, in just the last several years I've been called into a couple very small companies (less than 20 employees) to help resolve recalls where the root cause was identified to be inadequate design verification/validation testing of changed designs. These cases included FDA concurrence via direct onsite inspection and FDA Recall Coordinator remote audit of the recall strategy and Part 806 reporting. Both of those cases involved change order forms written with the best of intentions, thus containing all kinds of canned questions aimed at assuring proper consideration of the design change. Yet even with such well-intended questions on the change control forms, insufficient design verification/validation nevertheless prevailed and resulted in recalls.  Such outcomes should be no real surprise though because, after all, that is precisely how change control forms were always designed and managed in the decades prior to design controls becoming a regulatory requirement.  Indeed, primary reliance on such canned questions runs counter to a fundamental intent of design controls, which is to dynamically process design changes using methodical, systematic design control concepts.

     

    Look, there are without a doubt certain types of canned questions needed on every change control form. And maybe it doesn't hurt to throw in a question or two about particular hot-button topics. And I'm even convinced that there are some QMS subsystems (but not design change) where a form's canned questions can fill the gap left by minimally-trained personnel.  But the aforesaid cases and history prove that when the same canned standardized questions are used to identify the required design verification/validation testing for every design change, then such an approach too often leads to inadequate assessment of the design verification/validation requirements.  I believe this counterintuitive effect happens because such questions tend to give the design team a false sense of security and understanding about the change, consequently stifling the critical thought needed to assure proper design verification/validation planning.

     

    A final note from the aforementioned cases is that FDA gave no leniency regarding the recalling firms' small size and proven lack of understanding about proper design controls. But this also should be no surprise; remember FDA's public statements when promulgating its regulatory requirements prohibiting medical device manufacturers from having insufficient resources and training. Accordingly, I would urge caution to any design-control-regulated organization trying to do business in this regulated environment without first involving:

     

    1. someone onboard (internally or externally) who has a proper understanding of design controls; and
    2. a change control form that methodically yet dynamically forces consideration of the affected design inputs and outputs as the primary means for deriving the appropriate design verification/validation testing.


    ------------------------------
    Kevin Randall, ASQ CQA, RAC (U.S., Canada, Europe)
    Principal Consultant
    ComplianceAcuity, Inc.
    Golden CO
    United States
    www.complianceacuity.com
    © Copyright 2018 by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------